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1.  INTRODUCTION 

The  Automated  Manufacturing  Research  Facility  (AMRF)  of  the  National  Bureau  of 
Standards  is  a laboratory  for  studying  metrology  and  standards  issues  related  to  the 
automation  of  small- batch,  discrete-parts  manufacturing* 1.  The  Geometry  Modeling 
Project  of  the  AMRF  was  established  to  develop  the  geometry  modeling  technology 
needed  to  support  the  automated,  real-time,  manufacturing  control  systems  that  the 
AMRF  represents.  The  experience  of  researchers  in  the  AMRF  has  shown  that  control 
processes  in  an  automated  system  require  real-time,  on-line  access  to  geometric  data  for 
parts,  tools,  fixtures,  and  other  resources.  To  provide  the  performance  required  by 
these  processes,  multiple  representations  of  part  geometries  must  be  maintained.  The 
representation  of  part  functionality  (e.g.,  mating  parts  for  assembly  or  fixturing) 
requires  storing  the  relationships  between  geometric  features  of  different  parts.  Also, 
geometric  data  must  be  related  to  other  information  in  factory  data  bases,  such  as 
process  plans,  quality  data,  inventory,  and  tolerances.  The  management  of  multiple  data 
representations,  providing  access  to  data  in  a uniform  manner  to  all  facility  processes, 
and  maintaining  consistency  among  the  related  data  distributed  throughout  an  automated 
factory  such  as  the  AMRF  is  a major  challenge. 

This  paper  is  an  overview  of  the  approach  being  taken  toward  the  modeling  and 
management  of  part  geometry  data  in  the  AMRF.  This  project  will  develop  the  under- 
standing and  capabilities  needed  to  support  the  AMRF  through  the  implementation  of  a 
system,  called  the  Geometry  Data  System,  that  will  manage  all  model  information  that  is 
needed  to  perform  automated  manufacturing  operations.  The  Geometry  Data  System 
implements  the  following  functions:  provide  uniform  access  to  all  model  data  required 
by  different  control  processes;  provide  a set  of  tools  for  manipulating  data  in  various 
representations;  make  the  capabilities  of  particular  geometry  modeling  systems  available 
to  application  processes;  and  associate  application- specific  data  to  model  information. 
The  experience  gained  in  implementing  the  Geometry  Data  System  will  provide  input  to 
national  standardization  efforts  such  as  the  Product  Data  Exchange  Specification  (PDES) 
[SMTT86]  being  developed  by  ANSI  and  the  Dimensional  Measurement  Interface  Specifica- 
tion (DMIS)  [CAMI86]  being  developed  by  CAM-I,  Inc. 

The  functions  of  the  Geometry  Data  System  were  chosen  because  of  the  diverse  needs 
of  the  part  geometry  data  in  automated  manufacturing.  Part  geometry  data  in  the 

AMRF  consists  of  all  of  the  relevant  data  about  a pan  to  be  machined:  its  basic 


Commercial  products  are  identified  for  descriptive  purposes.  Such  identification  does 
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The  AMRF  has  been  described  elsewhere  (see  [SIMP82]).  An  extensive  bibliog- 
raphy of  AMRF  research  is  available  ([NANZ84]). 
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dimensions,  its  features,  and  its  tolerances.  Each  application  in  the  AMRF  tends  to 
have  its  own  particular  representation  of  these  data.  That  is  to  say,  each  application 
creates,  keeps,  and  uses  the  data  in  some  particular  way  according  to  its  processing 
requirements.  For  instance,  the  Cleaning  and  Deburring  Workstation  is  interested  in 
"deburring  edges"  (edges  that  must  have  burrs  removed),  and  the  order  of  machining  of 
the  faces  adjacent  to  each  deburring  edge.  The  Inspection  Workstation  uses  tolerances 
between  functionally  important  geometric  features  for  quality  control.  The  Process 
Planning  System  uses  groupings  of  geometry  data  to  form  machinable  features  such  as 
pockets,  holes,  grooves,  chamfers,  and  so  on.  We  want  to  pool  all  these  versions  of 
part  geometry  data  together  to  form  an  integral  part  of  the  facility,  so  that  the  various 
applications  are  relieved  of  the  burden  of  geometry  data  management,  and  yet  still  get 
to  use  the  geometry  data  in  their  special  way  of  processing. 

This  paper  describes  our  approach  to  the  implementation  of  the  Geometry  Data  System, 
the  applications  supported  by  the  system,  and  how  geometry  data  flows  through  the 
AMRF  through  the  operation  of  the  Geometry  Data  System. 


2.  APPROACH 

Our  approach  to  the  implementation  of  the  Geometry  Data  System  is  to  apply  three 
technologies  from  computer  science.  First,  formal  language  syntax  is  used  to  specify 
geometry  data  and  their  applications  as  a part  model.  This  syntax  allows  parsers  to  be 
built  on  each  AMRF  system  to  interpret  the  geometry  data  language.  Second,  data 
modeling  tools  are  used  to  build  the  data  structures  of  the  pan  model,  so  as  to  provide 
a formal  definition  of  the  meaning  of  pan  model  entities.  Third,  database  management 
technology  is  used  to  manage  the  geometry  data. 


2.1.  LANGUAGE 

Pan  models  are  communicated  within  the  AMRF  by  means  of  data  base  reports , which 
are  ASCII  text  files  containing  the  pan  model  data.  The  format  of  these  repons  is 
formally  specified  by  a grammar  in  Backus  Naur  Form  (BNF)  [HOPP87].  A typical  pan 
model  repon  is  illustrated  in  Figure  1.  The  pan  model  repon  format  constitutes  a 

language  by  which  applications  communicate  pan  geometry  in  the  AMRF. 

The  repon  format  is  defined  in  five  sections.  The  header  section  specifies  identifying 
information  and  global  data  about  a pan  — its  unique  name  in  the  AMRF,  its  group 
technology  code,  its  drawing  number,  the  name  of  its  designer,  and  the  pan  material 
may  all  be  specified.  The  functionality  section  specifies  the  geometric  tolerances  on  a 
pan  with  respect  to  its  functions  for  quality  control.  The  feature  section  specifies 
application-specific  information  about  the  pan.  A feature  in  the  features  section 
specifies  the  particular  way  an  application  uses  the  design  data  of  a pan  — for 
example,  machinable  features  used  for  process  planning,  cleaning  and  deburring  features 
for  the  generation  of  deburring  paths,  and  inspection  features  for  the  inspection 
workstation.  The  topology  section  describes  the  connectivity  relationships  of  the  basic 
geometry  data.  These  geometry  data  are  specified  in  the  geometry  section. 

As  a consequence  of  using  formal  language  techniques,  we  have  parsers  and  data 
assemblers  on  all  applications  using  the  Geometry  Data  System.  The  parsers  generate 
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internal  data  structures  from  the  database  report  and  the  data  assemblers  go  the  other 
direction  — they  generate  database  reports  from  the  internal  data  structures. 


2.2.  GEOMETRY  DATA  MODEL 

In  the  geometry  data  model,  the  basic  geometry  data  of  a part  are  organized  in  a 
boundary  representation  [MORT85].  In  this  representation,  a part  is  described  by  its 
topological  entities  and  its  geometrical  entities,  as  shown  in  Figure  2.  The  topological 
entities  are  structured  hierarchically  in  the  order:  solid,  shell,  face,  loop,  edge,  and 
vertex.  The  geometrical  entities  are  surface,  curve,  point,  and  unit  vector  (direction). 
The  connectivity  relationships  of  the  geometry  data  of  a part  are  provided  by  its 
topological  entities,  so  that  one  can  access  the  faces  of  a part,  the  adjacent  faces  of  an 
edge,  the  edges  on  a face,  and  so  on.  The  geometrical  entities  of  a part  are  accessed 
through  its  topological  entities,  so  that  surfaces  are  accessed  through  faces,  curves 
through  edges,  and  points  through  vertices. 

The  AMRF  part  model  was  initially  developed  in  Smalltalk-80  [GOLD83]  on  a Tektronix 
4404  AI  workstation.  The  purpose  of  the  implementation  was  to  develop  and  test  the 
model,  to  verify  that  it  would  support  the  AMRF  applications,  and  to  provide  a proto- 
type implementation  for  use  in  the  AMRF. 

Smalltalk  was  chosen  because  it  is  a language  in  which  objects  and  their  behavior  are 
the  focus  of  attention  for  the  programmer,  rather  than  data  structures  and  control.  In 
Smalltalk,  programs  are  developed  and  run  by  defining  classes  of  objects,  creating 
instances  of  these  classes,  and  sending  messages  to  these  instances.  A Smalltalk  class 
defines  both  the  data  structure  that  will  make  up  each  instance  of  the  class  and  the 
behavior  of  each  instance  (i.e.,  how  it  will  respond  to  messages)2.  A class  definition  is 
itself  an  instance  of  the  Smalltalk  class  Behavior.  Any  instance  of  a Behavior  (that  is, 
any  class  definition)  can  respond  to  the  message  "new"  and  will  create  a new  instance 
of  that  class.  The  class  definition  then  determines  how  that  instance  will  respond  to 
messages. 

We  have  implemented  a class  Topology  to  model  the  topological  entities  in  the  AMRF 
part  model.  A portion  of  the  Smalltalk  definition  of  this  class  is  shown  in  Figure  3. 
As  can  be  seen  at  the  top  of  the  lower  display  panel,  all  topological  entities  have  a 
name,  a set  of  subentities  and  a set  of  superentities.  The  latter  two  refer  to  the 
topological  hierarchy  shown  in  Figure  2.  (Thus,  for  instance,  a shell  as  a topological 
object  has  a solid  as  a superentity  and  a set  of  faces  as  subentities.)  As  shown  in  the 
third  panel  on  the  top,  all  topological  objects  share  a common  set  of  routines  (not 
displayed)  for  editing  and  accessing  object  definitions,  for  printing,  for  initialization, 
and  for  error  handling. 

The  class  Topology  is  refined  through  the  definition  of  subclasses  for  particular  types  of 
topological  objects.  The  subclasses  inherit  all  the  properties  of  the  Topology  definition, 
while  providing  additional  behavior  (routines),  data  definitions,  and  identity  to  specific 
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A Smalltalk  class  corresponds  roughly  to  the  idea  of  an  "abstract  data  type"  in 
programming  language  theory  [GUTT77],  and  to  a typed  lambda  calculus  function  in 
mathematical  logic  [CARD85]. 
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objects.  The  complete  list  of  Topology  subclasses  is  shown  in  the  bottom  panel  of 
Figure  3.  Reading  down  the  figure,  the  EdgeLoop  class  associates  a set  of  orientations 
to  the  subentities  of  edge  loops  (i.e.,  edges)  that  defines  the  counterclockwise  traversal 
direction  of  edge  loop  instances.  Shell  objects  have  no  additional  data  than  that 
defined  for  all  Topology  objects,  but  are  identifiable  as  shells  by  virtue  of  being 
instances  of  class  Shell.  Solid  instances  represent  individual  parts.  Each  Solid  instance 
maintains  a dictionary  of  the  topological  objects  that  constitute  that  solid.  These 
dictionaries  are  used  for  efficient  access  to  the  solid.  The  remaining  classes  are 

refinements  of  a class  TopologyWithGeometry,  that  represents  the  fact  that  faces,  edges, 
and  vertices  each  have  an  underlying  geometric  representation.  The  TopologyWith- 
Geometry class  implements  a common  representation  and  access  mechanism  for  this 
model  TopologyWithGeometry  has  two  subclasses,  TopologyWithOrientedGeometry,  that 
implements  the  concept  of  oriented  geometry  shared  by  faces  and  edges,  and  Vertex,  for 
winch  the  geometry  (points  in  space)  does  not  have  an  orientation.  Faces  and  edges 
are  implemented  by  parallel  class  hierarchies  that  are  used  to  distinguish  between  closed 
topology  (such  as  circles  or  spheres)  which  have  no  boundary  subentities,  and  open 
topology  (such  as  circular  arcs  or  spherical  patches)  which  do  have  a boundary. 

The  geometry  objects  associated  with  TopologyWithGeometry  subclasses  are  instances  of 
a class  Geometry,  shown  in  Figure  4.  The  subclasses  of  Geometry  are  the  specific 
geometric  objects  that  can  be  represented  in  the  Smalltalk  implementation  and  in  the 
AMRF  part  model  format.  The  geometry  classes  are  grouped  into  abstract  classes 
Curve3D,  representing  all  curve  objects,  Point3D,  representing  all  point  objects,  and 
Surface3D,  representing  all  surface  objects.  A subclass  of  Point3D,  UnitVector3D, 
represents  directions  in  space.  The  operations  on  the  Geometry  class  and  its  subclasses 
describes  the  properties  of  geometric  objects  and  the  relationships  between  them.  While 
the  current  implementation  is  relatively  limited  in  the  types  of  geometry  that  can  be 
modeled,  it  can  easily  be  extended  by  defining  additional  subclasses  of  Geometry. 


23.  GEOMETRY  DATA  MANAGEMENT 

The  application  processes  in  the  AMRF  access  the  geometry  data  through  the  AMRF 
distributed  database  system,  called  Integrated  Manufacturing  Data  Administration  System, 
or  IMDAS  for  short  [BARK86].  The  Geometry  Data  System  is  a database  management 
system  within  the  distributed  architecture.  It  is  a relational  database,  implemented  in 
RIM3,  together  with  software  for  handling  requests  dealing  with  pan  model  data.  The 
operation  of  this  architecture  is  shown  in  Figure  5.  When  an  application  issues  a data 
request,  it  is  parsed  by  IMDAS  and,  based  on  the  type  of  request,  routed  to  the 
Geometry  Data  System.  The  Geometry  Data  System  constructs  the  actual  relational 
database  commands  to  execute  the  request,  and  packages  the  results  in  the  Pan  Model 
Format  for  IMDAS  to  send  out  to  the  application. 

The  four  data  requests  are  INSERT,  SELECT,  DELETE,  and  UPDATE.  Basically,  the  data 
requests  that  an  application  needs  to  issue  are  "insen  a pan  model  into  the  geometry 
database",  "select  a pan  model  with  a specific  pan  name  from  the  geometry  database", 
"delete  a pan  model  from  the  geometry  database",  and  "update  a pan  model  in  the 
geometry  database".  The  user  of  the  database  system  need  not  be  aware  of  the  struc- 
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ture  of  the  data,  and  much  less  of  the  relational  database  operations  such  as  project, 
joint,  select,  and  union. 


3„  APPLICATIONS 

The  applications  currently  supported  by  the  Geometry  Data  System  are  Computer-Aided 
Design  (CAD),  Geometry  Modeling,  Process  Planning,  and  Cleaning  and  Deburring.  The 
applications  we  plan  to  include  are  Inspection,  the  Vertical  Workstation,  the  Horizontal 
Workstation,  the  Turning  Workstation,  Robot  Vision,  Robot  Control,  and  Assembly. 

The  CAD  system  is  the  source  of  geometric  data  for  pans  made  in  the  AMRF.  The 
data  generated  by  the  CAD  system  is  the  geometry  and  topology  of  the  ideal  pan,  along 
with  certain  administrative  data  about  the  pan. 

The  Geometry  Modeling  system  starts  with  the  design  data  and  adds  the  definitions  of 
tolerances,  datum  reference  frames,  datum  surfaces,  and  functional  features.  The  pan 
model  produced  by  the  Geometry  Modeling  system  is  the  definition  used  by  the  rest  of 
the  AMRF  systems. 

The  Process  Planning  system  requires  tolerance  and  shape  information  about  the  pan  so 
as  to  define  machinable  features  and  to  select  the  proper  manufacturing  processes.  The 
process  planning  system  also  generates  intermediate  workpiece  descriptions  in  the  form 
of  new  pan  models. 

The  Cleaning  and  Deburring  Workstation  uses  information  about  edges  and  adjacent 
faces  in  planning  and  executing  deburring  programs.  The  information  needed  are  the 
curve  equations  of  edges  to  be  deburred,  the  surface  orientations  of  the  faces  that  form 
each  edge,  and  the  order  of  machining  of  the  faces.  (Any  burrs  will  be  along  the  face 
that  was  machined  first)  The  latter  information  is  part  of  the  process  plan,  but  is 
stored  in  the  part  model  as  a "deburring"  machinable  feature. 

Inspection  requires  definitions  of  functional  features,  the  controlling  tolerances,  and  the 
datum  reference  frames  used  to  define  part  coordinate  systems.  These  data  are 
generated  by  the  Geometry  Modeling  system  and  are,  in  principle,  part  of  the  design  of 
the  part. 

The  Vertical,  Horizontal,  and  Turning  Workstations  will  require  the  definitions  of 
machinable  features  and  of  fixturing  requirements.  These  process- specific  data  will  be 
generated  by  the  Process  Planning  system  and  stored  as  components  of  the  part  model. 

Robot  Vision  and  Robot  Control  are  closely  coupled  systems  that  need  information  about 
part  shapes  to  plan  and  control  grasping  operations,  identification  of  parts,  and 
orienting  functions  performed  by  the  robots.  Much  of  the  data  used  by  the  Robot 
Vision  system  is  highly  specialized  part  representations  used  for  efficient  vision 
processing  algorithms.  The  relationship  between  these  specialized  representations  and 
the  current  AMRF  boundary  model  has  not  yet  been  fully  defined. 

Assembly  applications  require  information  about  mating  surfaces  between  parts,  as  well 
as  the  kind  of  material  handling  data  needed  by  Robot  Control.  Currently,  relationships 
between  different  parts  are  not  supported,  and  will  be  a major  extension  to  geometry 
modeling  capabilities  of  the  AMRF. 
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4.  DATA  FLOW 


The  flow  of  pan  geometry  data  through  the  AMRF  is  shown  in  Figure  6.  After  a pan 
is  designed  on  a CAD  system  (the  AMRF  currently  uses  CATIA  running  on  an  IBM 
4381),  its  basic  dimensions  are  extracted  from  the  CAD  system  and  stored  as  its  design 
data.  The  design  data  are  communicated  to  the  AMRF  database  system  as  a database 
report  in  the  format  described  above.  These  data  form  the  topology  and  geometry 
sections  of  the  AMRF  Pan  Model.  The  pan  model  is  then  retrieved  by  the  Geometry 
Modeling  System,  where  the  part  definition  is  expanded  to  include  pan  feature  and  pan 
functionality  data,  in  the  form  of  geometric  tolerances.  When  the  Geometry  Modeling 
System  stores  the  expanded  pan  model  in  the  AMRF  database,  it  contains  the  geometry, 
topology,  functional  features,  and  tolerances  of  the  part.  This  completes  the  design 
specification  for  the  pan.  The  pan  model  is  then  available  for  access  by  all  of  the 
AMRF  applications,  both  for  manufacturing  engineering  and  for  shop  floor  control. 

To  give  a specific  example.  Process  Planning  accesses  the  Pan  Model,  and  identifies 
groupings  of  geometric  entities  as  machinable  features.  It  then  updates  the  pan  model 
with  the  machinable  features  of  a pan.  These  machinable  features,  stored  in  the  pan 
model,  are  referenced  by  the  process  plans  produced  by  the  Process  Planning  system. 
These  features  are  then  used  by  equipment-level  programming  systems  (such  as  NC 
coding  and  robot  control  data  generation)  to  program  shop  floor  equipment.  At  this 
stage,  a pan  can  be  manufactured  automatically  on  the  AMRF  shop  floor. 

As  mentioned  earlier,  pan  functional  feature  data  and  geometric  tolerances  of  a pan 
are  entered  on  the  Geometry  Modeling  System.  This  system  was  built  on  top  of  a 
geometry  modeling  package  called  UNICAD4,  running  on  a Silicon  Graphics  IRIS  2400 
workstation.  The  user  can  define  features,  datum  reference  frames,  and  tolerances 
through  a combination  of  interactive  graphics  and  filling  forms  on  the  screen.  A typical 
screen  display  is  shown  in  Figure  7.  The  Geometry  Modeling  System  is  described  in 
detail  in  [CLAR87]. 


5.  CONCLUSION 

As  has  been  described,  pan  model  data  in  the  AMRF  is  a unifying  thread  from  design, 
through  modeling,  process  planning,  equipment  programming,  to  shop  floor  operations.  A 
key  to  the  successful  implementation  of  this  approach  has  been  to  provide  a structured 
methodology  for  the  preparation  and  handling  of  pan  data  at  all  stages  of  the  manufac- 
turing process.  This  methodology  was  developed  through  the  application  of  formal 
language  techniques,  data  modeling,  and  database  management  technologies. 

The  approach  being  taken  to  handling  pan  models  in  the  AMRF  is  evolutionary.  The 
current  system  supports  some,  but  not  all,  of  the  applications  envisioned.  As  geometry 
data  requirements  are  developed  for  other  AMRF  systems,  and  change  for  systems 
cunently  supported,  the  Geometry  Modeling  System  described  in  this  paper  will  change 
to  meet  those  needs. 
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There  are  several  types  of  geometry  data  that  are  not  supported  by  the  current  system. 
These  include  such  things  as  part  drawings  and  various  types  of  relationships  between 
part  models.  Part  drawings  are  generally  not  needed  within  the  AMRF.  The  intent  of 
this  work  is  to  support  automated  or  semi- automated  systems.  The  emphasis  has  been 
on  communicating  mathematically  precise  and  complete  part  models,  rather  than  on 
blueprints  that  require  human  interpretation.  As  such,  the  objectives  of  this  work  are 
complementary  to  such  standards  as  IGES  [ansisi]. 

There  is  one  set  of  requirements  that  has  not  been  addressed  that  is  expected  to  be 
very  important  This  is  the  modeling  and  representation  of  relationships  between 
different  part  models.  Such  relationships  are  needed  for  a variety  of  applications, 
including  revision  control,  the  relationship  of  a part  design  to  intermediate  workpiece 
geometries,  and  assembly  descriptions  (both  for  assembled  products  and  for  fixturing 
operations).  This  will  require  storing  cross-references  between  part  models,  as  well  as 
between  components  of  part  models  (such  as  between  mating  faces  on  different  parts). 
These  issues  are  extremely  complex,  from  the  point  of  view  both  of  the  engineering 
needs  and  of  the  data  management  requirements.  While  we  anticipate  addressing  some 
of  these  issues  in  the  near  future,  we  expect  that  it  will  be  many  years  before  the 
technology  will  have  been  developed  to  a point  comparable  to  that  available  for 
representing  individual  parts.  Developing  this  technology  within  the  framework  of  the 
AMRF  will  be  the  goal  of  our  future  work  on  geometric  modeling. 
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/PART  MODEL 
/HEADER 

PART.NAME  * 'PIFECLAMP.FV  . 
/END  .HEADER 
/TOPOLOGY 
/SHELLS 

SHL001;FAC001.FAC002. 

/FACES 


FAC014;  LOP014;LOP031; 

SUR014  ! 

FAC015;  LOP015,  LOP033;  SUR015  ♦ . 

i /“\rw i • . pr\z*Ai  £ 

SUR014 

LOP014;  EDG016  - . | 

LOP017;  EDG014 « . 

/ENDVF.RTICES 

/ENBJTOPOLOGY 

/GEOMETRY 

/SURFACES 

SUR001;  PLANE;  UNV002;  0.0  . 

SUR008;  PLANE;  UNV001;  0.703  . 

SUR009;  CYLINDER;  PT077;  UNV003;  0.281  . 
SUR010;  CYLINDER;  PT078;  UNV003;  0.281  . 
SUR01 1;  PLANE;  UNV002;  5.000 . 

SUR012;  PLANE;  UNV001;  0.0  . 

SUR013;  CYLINDER;  PT079;  UNV003;  0.500  . 


SUR014;  CYLINDER;  PT029;UNV002;  0.281  + 


D 


/ENDJURFACES 

/CURVES 

t cmni  ■ t rrv\ i 


/ENDLOOPS 

/EDGES 

EDG011;  VTX022,  VTX021;  CRV01 1 ♦ . 
EDG012;  VTX023.  VTX022;  CRV012  ♦ . 
EDG013;  VTX023.  VTX001;  CRV013  ♦ . 
EDG014;  ; CRV014  •¥  . 

g.  . r-asmi  c . 


CRV016;  CIRCLE;  PT029;  UNV002;  PT030 


LK  VU2U;  LIKLLfc.;  F1UJ/I  UNVUOl;  P1U38' 
/END^CURVES 

/POINTS 

PT001;  0.5. 0.0. 0.0  . 


EDG016 ; ; CRV016 


PT029;  0.406,  4.641,  0.0  . 


EDG018; ; CRV018  • 


PT028;  0.5465.4.641.0.0. 
/UNTT  VECTORS 


UNV002;  0, 1.0, 0 

uni  vuu3i  u.  u.  nr 


Figure  1.  The  Format  of  AMRF  Part 
Model  Data  Base  Reports 


Topology  Geometry 


• § 


Figure  2.  The  Topological  and  Geometric  Entities 
of  a Boundary  Representation 
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Figure  3.  The  Smalltalk-80  Topology  Class  Hierarchy 


SyltM^rtV^ty 


Figure  4.  The  Smalltalk-80  Geometry  Class  Hierarchy 


Application 


Figure  5.  Routing  of  Geometry  Data  Transactions 


Part  Specification 


Figure  6.  Flow  of  Part  Geometry  Data  in  the  AMRF 


Figure  7.  Screen  Image  of  the 

Geometry  Modeling  System 
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